A testability analysis for driving architectural synthesis

In this paper, we present a method for analyzing the testability of a circuit during the design process. Given a circuit specification, whatever the level of description from the behavioral level (initial specification) down to the Register Transfer Level (High Level Synthesis process result), the testability analysis returns values which represent the relative difficulty for computing input sequences for setting lines to appropriate patterns and driving errors to primary outputs. Delivered testability measures are well correlates to gate–level testability measures (e.g. Scoap) and can be used within high level synthesis to drive this process towards the generation of easily SATPG testable structures. Introduction The proposed method takes place in a High Level Synthesis (HLS) flow: typically, the input behavioral specification is synthesized in an output structural representation of the circuit at Register Transfer Level (RTL) where generated structure is composed of a controller and a datapath. Classically, many RTL designs can be synthesized from a given behavioral description achieving the same goals for several characteristics (area, performances, ...) but testability. Here we address the testability of the data–path assuming that the controller can be modified to be self–testable (e.g.[1]) and that a test mode allows to test the data–path regardless of the system mode operations. All along the synthesis process, the internal representation of the design is a Data Flow Graph (DFG) representing the elementary data transfers which have to be performed during the system mode operations between datapath elements. Initially the nodes in the DFG are variables and operations, then these behavioral elements are progressively mapped to structural elements (registers, operators) as the HLS proceeds. The goal of the method presented here is to early identify and predict testability problems. In the following section, we detail our testability constraints and measures. In the fourth section, we show how this information is used to drive the HLS process in order to solve these testability problems and to obtain easily SATPG testable structures. Experimental results are presented in the last section. Testability problems definition and related works Testability issues targeted in related works on High Level Synthesis for Testability (e.g. [2], [3], [4]) are mainly sequential depth reduction, loops reduction, and the increase of I/O registers. Their experimental results show that generated structures have higher fault coverage, shorter test generation time and comparable size when compared with designs synthesized for area only. But, most of these works do not considered testability bottlenecks induced by reconvergences or module transparence properties [5]. Furthermore, these works do not rely on testability measures. Consequently addressed synthesis for testability issues are done in a ”blind” way with regard to actual internal nodes testability. The behavioral testability method presented in [6] classifies the DFG variables into complete controllable/non–complete controllable and complete observable/non–complete observable ones. For example, a variable is of type complete controllable if there exists a sequence of executable paths such that after the execution of these paths, the content of that variable can take any possible value by adjusting the input values. Results are used to modify the input behavioral specification in order to increase accessibility. It must be stressed that in this method, test data justification and propagation paths are identified from data paths defined by the system mode flow. The method presented here gets rid off the above limitations. The testability analysis process determines the probability for justifying and propagating any test data to internal nodes. Furthermore, it explicitly